Method and system for managing message threads in converged ip messaging service

ABSTRACT

A mechanism to enable multiple message threads management in the context of the Converged IP Messaging (CPM) service and in the context of CPM inter-working with SMS is provided. A CPM user can simply start a message-based conversation with another CPM or Short Message Service (SMS) user without explicitly establishing a session beforehand. All messages that belong to a given conversation are displayed in the corresponding conversational view (i.e. window) in the CPM user device, even if the conversation is stopped and restarted at a later time, and even if there are multiple message threads available (currently active or stored) in the CPM device. Message structures and behavior of the CPM system elements to enable the functionalities above as well as a mechanism makes the message threads management possible even between a CPM user and an SMS user are also provided.

PRIORITY

This application claims priority under 35 U.S.C. § 119(a) to anapplication entitled “Method And System For Managing Message Threads InConverged IP Messaging Service” filed in the Korean IntellectualProperty Office on Nov. 13, 2006 and assigned Serial No. 2006-111783,the contents of which are hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and system for converged IPmessaging service, and in particular, to a method and system formanaging message threads in converged IP messaging service.

2. Description of the Related Art

Many different messaging services, such as Short Message Service (SMS),Multimedia Messaging Service (MMS), email, Instant Messaging (IM)service, etc., exist today. Although these services rely on differenttechnologies, user experiences the services provide partially overlapwith each other. For example, it is possible to send text messages usingall the services cited above, and all services above except for SMS cansupport the transfer of multimedia content.

Recently, there has been an emergence of a new type of convergedmessaging service in which the above-mentioned messaging services aresynthetically converged. As used herein, such a converged messagingservice is called a “Converged IP Messaging (CPM) service.” The CPMservice is an Session Initiation Protocol (SIP)-based service and isrequired to be capable of freely performing message communication withusers of existing messaging services as well as users of the CPMservice. Therefore, the CPM service needs to be capable of inter-workingwith the existing SMS service, IM service, MMS, Push to talk overCellular (PoC) service, etc. Further, inter-working between a messagingservice through established sessions and a messaging service withoutestablishment of sessions should be possible, and thus standardizationof such inter-working is now being in progress.

Usually, message transmission/reception in a CPM system is performedaccording to a process as shown in FIG. 1, and messagetransmission/reception in an SMS system is performed according to aprocess as shown in FIG. 2. In order to help understanding of themessage transmission/reception process in each system, FIGS. 1 and 2 arebased on an assumption that each system includes two users, althougheach system allows message transmission/reception between multipleusers. It is also assumed here that users do not explicitly establish asession before exchanging the messages, i.e. the user who wants to starta conversation can send a message immediately without first requestingthe creation of a session.

The CPM service is based on an SIP that provides a protocol to initiate,modify and terminate a session between users. To send messages withoutinitiating a session first, the CPM relies on the SIP MESSAGE extension.FIG. 1 illustrates a typical flow of a message sent from a first userand a second user, represented by a first CPM client 1 and a second CPMclient 3 respectively, via a CPM server 2.

In step 101, the first CPM client 1 sends a typical SIP MESSAGE having aconfiguration as shown in Table 1 to the CPM Server 2.

TABLE 1 MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCPuser1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From:sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID:asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plainContent-Length: 18 Hello Mark, are you there?

In step 103, the CPM server 2 receives the SIP MESSAGE, identifies ifthe second CPM client 3 is registered in the CPM server 2, and forwardsthe SIP MESSAGE having a configuration as shown in Table 2 to the secondclient 3.

TABLE 2 MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCPproxy.domain.com;branch=z9hG4bK123dsghds Via: SIP/2.0/TCPuser1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4Max-Forwards: 69 From: sip:user1 ©domain.com;tag=49394 To:sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGEContent-Type: text/plain Content-Length: 18 Hello Mark, are you there?

The second CPM client 3 receives the message in step 103, and sends backa “200 OK” message having a configuration as shown in Table 3 to the CPMserver 2 in step 105.

TABLE 3 SIP/2.0 200 OK Via: SIP/2.0/TCPproxy.domain.com;branch=z9hG4bK123dsghds; received=192.0.2.1 Via:SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;received=1.2.3.4 From: sip:user1@domain.com;tag=49394 To:sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1MESSAGE Content-Length: 0

Upon receiving the “200 OK” from the second CPM client in step 105, theCPM server 2 forwards a “200 OK” message having a configuration as shownin Table 4 to the CPM client 1 in step 107.

TABLE 4 SIP/2.0 200 OK Via: SIP/2.0/TCPuser1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 From:sip:user1@domain.com;;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0

The SMS follows the protocol defined in 3GPP [TS 23.040]. FIG. 2illustrates a typical message processing flow when a first MobileStation (MS) 4 sends a Short Message (SM) to a second MS 6 via a ShortMessage Service Center (SMSC) 5.

In step 201, the first MS 4 submits an SM to the SMSC 5 by using anSMS_SUBMIT Protocol Data Unit (PDU). At this time, the first MS 4 canalso request an SMS status report (SMS_STATUS_REPORT).

Upon receiving the SMS_SUBMIT PDU, the SMSC 5 confirms the reception ofthe SMS_SUBMIT PDU by sending an SMS_SUBMIT_REPORT PDU back to the firstMS 4 in step 203.

In step 205, the SMSC 5 forwards the SM to the second MS 6 through anSMS_DELIVER PDU. Then, in step 207, the second MS 6 acknowledges thereception of the SM by sending an SMS_DELIVER_REPORT PDU back to theSMSC 5. Upon receiving the SMS_DELIVER_REPORT PDU, the SMSC 5 sends anSMS_STATUS_REPORT PDU to the first MS 4 to report that the SM wassuccessfully delivered to the second MS 6 in step 209.

The SMS_SUBMIT PDU includes information elements (from [TS 23.040]) asshown in Table 5.

TABLE 5 Abbr. Reference P¹⁾ P²⁾ Description TP-MTI TP-Message-Type- M 2bParameter describing the message Indicator type. TP-RDTP-Reject-Duplicates M b Parameter indicating whether or not the SCshall accept an SMS-SUBMIT for an SM still held in the SC which has thesame TP-MR and the same TP-DA as a previously submitted SM from the sameOA TP-VPF TP-Validity-Period- M 2b Parameter indicating whether or notFormat the TP-VP field is present. TP-RP TP-Reply-Path M b Parameterindicating the request for Reply Path. TP-UDHI TP-User-Data-Header- O bParameter indicating that the TP-UD Indicator field contains a Header.TP-SRR TP-Status-Report- O b Parameter indicating if the MS is Requestrequesting a status report. TP-MR TP-Message-Reference M I Parameteridentifying the SMS-SUBMIT. TP-DA TP-Destination-Address M 2-1 Addressof the destination SME. 2o TP-PID TP-Protocol-Identifier M o Parameteridentifying the above layer protocol, if any. TP-DCSTP-Data-Coding-Scheme M o Parameter identifying the coding scheme withinthe TP-User-Data. TP-VP TP-Validity-Period O o/7o Parameter identifyingthe time from where the message is no longer valid. TP-UDLTP-User-Data-Length M I Parameter indicating the length of theTP-User-Data field to follow. TP-UD TP-User-Data O 3)

The SMS_DELIVER PDU includes information elements (from [TS 23.040]) asshown in Table 6.

TABLE 6 Abbr. Reference P¹⁾ R²⁾ Description TP-MTI TP-Message-Type- M 2bParameter describing the message Indicator type. TP-MMSTP-More-Messages-to- M b Parameter indicating whether or not Send thereare more messages to send TP-RP TP-Reply-Path M b Parameter indicatingthat Reply Path exists. TP-UDHI TP-User-Data-Header- O b Parameterindicating that the TP-UD Indicator field contains a Header TP-SRITP-Status-Report- O b Parameter indicating if the SME has Indicationrequested a status report. TP-OA TP-Originating-Address M 2-1 Address ofthe originating SME. 2o TP-PID TP-Protocol-Identifier M o Parameteridentifying the above layer protocol, if any. TP-DCSTP-Data-Coding-Scheme M o Parameter identifying the coding scheme withinthe TP-User-Data. TP-SCTS TP-Service-Centre- M 7o Parameter identifyingtime when the Time-Stamp SC received the message. TP-UDLTP-User-Data-Length M I Parameter indicating the length of theTP-User-Data field to follow. TP-UD TP-User-Data O 3)

The TP-UD (User Data) contains the message to be sent. The message canbe preceded by a header inside the TP-UD. The presence of the header isindicated by the TP-UDHI (User Data Header Indicator) informationelement, i.e., a TP-UDHI set to “1” indicates that TP-UD is a header.

The header in the TP-UD may be structured as shown in Table 7 (from [TS23.040]).

TABLE 7 Field Length Length of User Data Header 1 octetInformation-Element-Identifier “A” 1 octet Length of Information-Element“A” 1 octet Information-Element “A” Data 0 to “n” octetsInformation-Element-Identifier “B” 1 octet Length of Information-Element“B” 1 octet Information-Element “B” Data 0 to “n” octetsInformation-Element-Identifier “X” 1 octet Length of Information-Element“X” 1 octet Information-Element “X” Data 0 to “n” octets

The “Information-Element-Identifiers” are predefined values; they allrefer to a specific meaning. The list of identifiers and their meaning(for SMS only) are shown in Table 8 (from [TS 23.040]):

TABLE 8 VALUE Classifi- Repeat- (hex) MEANING cation ability 00Concatenated short SMS Control No messages, 8-bit reference number 01Special SMS Message SMS Control Yes Indication 02 Reserved N/A N/A 03Value not used to N/A N/A avoid misinterpretation as <LF> character 04Application port SMS Control No addressing scheme, 8 bit address 05Application port SMS Control No addressing scheme, 16 bit address 06SMSC Control Parameters SMS Control No 07 UDH Source Indicator SMSControl Yes 08 Concatenated short SMS Control No message, 16-bitreference number 09 Wireless Control SMS Control Note 3 Message Protocol. . . . . . . . . . . . 1B-1F Reserved for future N/A N/A EMS features(see subclause 3.10) 20 RFC 822 E-Mail Header SMS Control No 21Hyperlink format element SMS Control Yes 22 Reply Address Element SMSControl No 23 Enhanced Voice Mail SMS Control No Information 24-6FReserved for future use N/A N/A 70-7F (U)SIM Toolkit Security SMSControl Note 1 Headers 80-9F SME to SME specific use SMS Control Note 2A0-BF Reserved for future use N/A N/A C0-DF SC specific use SMS ControlNote 2 E0-FF Reserved for future use N/A N/A Note 1: The functionalityof these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, therepeatability is not within the scope of this document and will not bedetermined here. Note 2: The functionality of these IEIs is used in aproprietary fashion by different SMSC vendors, and therefore, are notwithin the scope of this technical specification. Note 3: Thefunctionality of these IEIs is defined by the WAP Forum and thereforethe repeatability is not within the scope of this document and will notbe determined here.

The message transmission according to the above-mentioned process may beperformed either only once between two users or repeatedly multipletimes between the same two users. That is, the users may exchangemessages like a conversation through the SMS or CPM service. In thisprocess, two users can handle a conversation by just exchanging a seriesof messages to each other without explicitly establishing a sessionbeforehand. Therefore, messages that are transmitted to or received fromthe same counterpart are displayed on an individual window of a user.The same concept is also applicable to the CPM service in which messagesare transmitted/received after setup of a session. It is impossible todisplay a set of messages, which a CPM client has transmitted to orreceived from the same counterpart according to the CPM service, in asingle window, for example, a conversational view. Further, it is alsoimpossible to provide a conversational view including previouslyexchanged messages in the case of restarting the conversation later,because messages are not bound to any particular session, and thus arenot linked to each other.

SUMMARY OF THE INVENTION

The present invention has been made to solve the above-mentionedproblems occurring in the prior art, and the present invention providesa method and system for simultaneously providing a single message groupincluding messages transmitted/received between two Converged InternetProtocol Message (CPM) clients to the users.

Also, the present invention provides a method and system forsimultaneously providing a single message group including messagestransmitted/received between users of heterogeneous services, forexample, between a CPM client of a CPM service requiring session setupand a Short Message Service (SMS) user of an SMS that does not requiresession setup, so that the CPM client can effectively transmit/receive aconversational message without determining if the counterpart of theconversational message is a user for whom the CPM service is supported.

In accordance with an aspect of the present invention, there is provideda CPM system for managing multiple message threads and supporting aSession Initiation Protocol (SIP) based Converged Internet ProtocolMessaging Service (CPMS), the CPM system comprises a CPM client forwhich the CPMS is supported; a non-IP Multimedia Subsystem (IMS) clientthat has not joined an IMS service; and an Inter-Working Function (IWF)for, when a recipient client of the CPM client is appointed as thenon-IMS client by a CPM server and the IWF receives an SIP message forconversational message communication, converting a message format of theSIP message into a message format that can be received by the recipientclient, inserting a thread identifier (ID) included in the SIP messageinto the converted message, and then transmitting the converted messageto the recipient client via a server supporting the recipient client.

In accordance with another aspect of the present invention, there isprovided a CPM system for managing multiple message threads andsupporting an SIP based CPMS, the CPM system comprises a CPM client forwhich the CPMS is supported; a non-IMS client that has not joined an IMSservice; and an IWF for, when a recipient client of the CPM client isappointed as the non-IMS client by a CPM server and the IWF receives anSIP message for conversational message communication, detecting andstoring a thread ID from the SIP message, converting a message format ofthe SIP message into a message format that can be received by therecipient client, transmitting the converted message to the recipientclient via a server supporting the recipient client, converting amessage received from the recipient client within a predetermined validreply period to an SIP message, inserting the stored thread ID into theconverted SIP message, and transmitting the SIP message to the CPMclient via the CPM server.

In accordance with another aspect of the present invention, there isprovided a CPM system for managing multiple message threads andsupporting an SIP based CPMS, the CPM system comprises a CPM client forwhich the CPMS is supported; a MS for which an SMS is supported; an IWFfor, when a recipient client of the CPM client is appointed as the MS bya CPM server and the IWF receives an SIP message for conversationalmessage communication, converting a message format of the SIP messageinto a message format of an SMS SUBMIT Protocol Data Unit (SMS_SUBMITPDU), setting sub-address digits of a TP destination address of theSMS_SUBMIT PDU to a thread ID detected from the SIP message, and thentransmitting the SMS_SUBMIT PDU to the SMSC; and the SMSC for receivingthe SMS_SUBMIT PDU, converting the SMS_SUBMIT PDU to an SMS DELIVERYProtocol Data Unit (SMS_DELIVER PDU), setting sub-address digits of a TPoriginator address of the SMS_DELIVERY PDU to the thread ID, and thentransmitting the SMS_DELIVERY PDU to the MS.

In accordance with another aspect of the present invention, there isprovided a method for managing a message thread including a series ofmessages transmitted to and received from a same counterpart by a CPMclient supporting an SIP based CPMS, the method comprises receiving arequest for transmission of a message for conversational messagecommunication from a recipient; when the message is a first message of anew message thread associated with the recipient, allocating a newthread ID to the new message thread, storing the new thread ID inrelation to the recipient, inserting the new thread ID into the message,and then transmitting the message; when the message is a subsequentmessage in an existing message thread associated with the recipient,detecting a thread ID allocated in accordance with the existing messagethread, inserting the allocated thread ID in the message, and thentransmitting the message; receiving a message for conversational messagecommunication; and when the received message includes a thread ID,providing a user with the received message with messages included in amessage thread corresponding to the thread ID included in the receivedmessage.

In accordance with another aspect of the present invention, there isprovided a method for managing a message thread including a series ofmessages transmitted to and received from a same counterpart by a CPMclient supporting an SIP based CPMS, the method comprises transmitting,by a CPM client for conversational message communication, an SIP messagethat includes a thread ID allocated to a message thread associated witha recipient appointed as a non-IMS client that has not joined an IMSservice; and when an IWF receives the SIP message through a CPM server,converting a message format of the SIP message into a message formatthat can be received by the recipient, inserting the thread ID in theconverted message, and then transmitting the converted message to therecipient, by the IWF.

In accordance with another aspect of the present invention, there isprovided a method for managing a message thread including a series ofmessages transmitted to and received from a same counterpart in a CPMsystem supporting an SIP based CPMS, the method comprises transmitting,by a CPM client for conversational message communication, an SIP messagethat includes a thread ID allocated to a message thread associated witha recipient appointed as a non-IMS client that has not joined an IMSservice; and when an IWF receives the SIP message through a CPM server,storing the thread ID, an address of the CPM client, and a recipientaddress, setting a predetermined valid reply period corresponding to thethread ID, converting a message format of the SIP message into a messageformat that can be received by the recipient, and transmitting theconverted SIP message to the recipient through a server supporting therecipient, by the IWF; and when the IWF receives a message from therecipient within the predetermined valid reply period, converting themessage received from the recipient into an SIP message, inserting thestored thread ID into the SIP message, and then transmitting the SIPmessage to the CPM client via the CPM server, by the IWF.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features and advantages of the presentinvention will become more apparent from the following detaileddescription when taken in conjunction with the accompanying drawings, inwhich:

FIG. 1 illustrates a typical flow of processing a CPM message;

FIG. 2 illustrates a typical flow of processing an SM;

FIG. 3 illustrates a process for processing a message in a system inwhich a CPM system and a short message system inter-work;

FIG. 4 illustrates an operation of an originator CPM client according tothe present invention;

FIG. 5 illustrates an operation process of the CPM client 10 accordingto the present invention;

FIG. 6 illustrates a message processing procedure of a short messagesystem and a CPM system inter-working with each other according to thepresent invention;

FIG. 7 illustrates a process of transmitting a short message by an MS ina case where a header of a TP-UD of a transmitted SM includes a threadID according to the present invention;

FIG. 8 illustrates an operation of an IWF according to the presentinvention;

FIG. 9 illustrates a message processing procedure by a CPM system and anSM system inter-working with each other according to the presentinvention; and

FIG. 10 illustrates an operation of an IWF according to the presentinvention.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENT

Hereinafter, exemplary embodiments of the present invention will bedescribed with reference to the accompanying drawings. In the followingdescription, the same elements will be designated by the same referencenumerals although they are shown in different drawings. Further, adetailed description of known functions and configurations incorporatedherein will be omitted when it may make the subject matter of thepresent invention rather unclear.

As used herein, a series of messages transmitted/received between aConverged Internet Protocol Message (CPM) client using the CPM serviceand the same counterpart is called a “messages thread.” The presentinvention provides a more friendly user interface by grouping anddisplaying one or more messages included in a message thread on a singlewindow when a CPM client provides the message thread to a user.According to the present invention, when a CPM client performs messagecommunication with a particular counterpart, an identifier is assignedto a message thread corresponding to the particular counterpart and themessage is then transmitted with the identifier. At this time, theparticular counterpart can be more than one. Further, according to thepresent invention, the same identifier is included in a message that theCPM client receives from the particular counterpart, so that the CPMclient provides the message thread relating to the particularcounterpart to the user through a single window. In the presentinvention, the window in which the messages are displayed is called a“conversational view,” and an identifier allocated to each messagethread or an identifier allocated to a counterpart of the messagecommunication is called a “thread identifier (ID).” Further, as usedherein, a CPM client includes a Mobile Station (MS) that provides a userinterface between a user and a CPM system in a communication networkproviding a CPM service (for example, the user interface directlyprovides a message to the user and receives an input from the user).Further, the counterpart of the CPM client in the message communicationeither may be a CPM client or may not be a CPM client. For example, thecounterpart may be either a mobile station of a messaging servicetransmitting/receiving messages without session setup or a client forwhich an IP Multimedia Service (IMS) is not supported.

The present invention can be applied not only to a message servicebetween CPM clients but also to another messaging system inter-workingwith the CPM system, which includes, for example, a messaging systemthat does not provide the IMS and a system providing a messaging servicewithout session setup. Therefore, in the embodiments described below, asystem in which a CPM system and an Short Message Service (SMS) systeminter-work with each other is discussed to show an application of thepresent invention to a messaging service between a CPM system andanother messaging system as well as a process of providing a messagethread in a messaging service between CPM clients.

The CPM service is a Session Initiation Protocol (SIP)-based servicewhich requires session setup for a messaging service, while the SMSservice does not require session setup for messagetransmission/reception. Therefore, a CPM system and an SMS systeminter-work through an Inter-working Function (IWF). The IWF includesvarious functions, one representative example of which is the conversionof message formats of a short message and a CPM service message(hereinafter, a “CPM message”). As a result, even when one party sends aCPM message, a counterpart may receive a short message. Further, evenwhen one party sends a short message, a counterpart may receive a CPMmessage. Such a message processing flow is illustrated in FIG. 3. FIG. 3illustrates a process for processing a message in a system in which aCPM system and a short message system inter-work, wherein a CPM client10 transmits a CPM message to a mobile station 60 for which SMS issupported.

Referring to FIG. 3, a CPM client 10 transmits an SIP message through aCPM server 20 to the IWF 30 in steps 301 and 303. The IWF 30 convertsthe message format from the CPM service to the SMS in step 305, andtransmits the message to the Short Message Service Center (SMSC) 50through the SMS SUBMIT Protocol Data Unit (SMS_SUBMIT PDU) in step 307.Then, The Short Message Service Center (SMSC) 50 transmits the messageto the MS 60 through the SMS DELIVERY Protocol Data Unit (SMS_DELIVERPDU) in step 311. The MS 60 transmits an SMS_DELIVER_REPORT PDU to theSMSC 50 in step 313, and the SMSC 50 transmits an SMS_STATUS_REPORT PDUto the IWF 30 in step 315. Upon receiving the SMS_STATUS_REPORT PDU instep 315, the IWF 30 transmits “200 OK” through the CPM server 20 to theCPM client 10 in steps 317 and 319.

In the case of message transmission as described above, the CPM client10 cannot differentiate a message thread related to the MS 60 from amessage thread related to another communication object. Therefore,according to the present invention, the CPM client 10 inserts a threadID in an SIP message before transmitting the SIP message. For example,in the present invention, a new eXtensible Markup Language (XML)document containing a <thread-id> tag is included in the SIP message.Table 9 shows an example of such an XML document.

TABLE 9 <?xml version=“1.0” encoding=“UTF-8”?> <message-groupingxmlns=“urn:oma:params:xml:ns:cpm:message-grouping”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:schemaLocation=“urn:oma:params:xml:ns:cpm:message-grouping”><note>This information is to sort messages of the same subjects </note><thread-id>Teleworkers</thread-id> </message-grouping>

Further, an XML schema corresponding to Table 9 is illustrated in Table10.

TABLE 10 <?xml version=“1.0” encoding=“UTF-8”?> <xs:schematargetNamespace=“urn:oma:params:xml:ns:cpm:message-grouping”xmlns:xs=“http://www.w3.org/2001/XMLSchema”xmlns=“urn:oma:params:xml:ns:cpm: message-grouping”elementFormDefault=“qualified” attributeFormDefault=“unqualified”><xs:element name=“note” type=“xs:string” minOccurs=“0”/> <xs:elementname=“thread-id” type=“xs:string” minOccurs=“0”/> <xs:any Attributenamespace=“##other”/> </xs:schema>

In the schema shown in Table 9, “note” refers to a message groupingtext, “Thread-id” refers to a messaging subject or a value used forgrouping, and “other” refers to a place holder for future extensions. Anoperation of an originator CPM client 10 for inserting the XML havingthe above-described configuration into an SIM message is illustrated inFIG. 4.

Referring to FIG. 4, when a CPM client 10 receives a request to send amessage from the user in step 401, the CPM client 10 proceeds to step403, in which the CPM client checks if the message is the first messageof a new thread or a follow-up message of an existing thread. Accordingto an embodiment of the present invention, the thread database stores anaddress corresponding to a particular subject and a thread ID allocatedto message thread corresponding to the particular subject when the CPMclient 10 exchanges messages with the particular subject forconversational messaging communication. The CPM client 10 has the threaddatabase. Further, the thread database may store messages relating toeach thread ID in a manner corresponding to the corresponding thread IDor may store messages relating to each thread ID at a positioncorresponding to the corresponding thread ID. The messages stored inthis way are used for configuration of a conversational view. Therefore,referring to FIG. 4 again, when the CPM client 10 has exchanged amessage with the message recipient, the message recipient has beenallocated a thread ID, the allocated thread ID has been stored in thethread database, and the message corresponds to a follow-up message ofan existing thread. Further, when the CPM client 10 has never received amessage from the message recipient and the transmitted message is thefirst message, the message starts a new thread. Therefore, when anallocated thread ID exists in the address of the recipient of themessage requested to be transmitted in step 401, the CPM client 10detects the corresponding thread ID in step 405, and then proceeds tostep 411. In contrast, when there is no thread ID allocated to therecipient, the CPM client 10 generates a new thread ID in step 407,stores the generated thread ID with a relation to the address of therecipient of the message in step 409, and then proceeds to step 411. Instep 411, the CPM client 10 generates and transmits an SIP messageincluding the detected thread ID or the generated thread ID.

After transmitting the message or identifying a related thread ID, theCPM client 10 may display a conversational view including the message,which corresponds to the recipient. In other words, the CPM client 10may load messages stored in the thread database in relation to thethread ID corresponding to the message or load messages by referring tothe storage positions of the messages stored in the thread database inrelation to the thread ID, thereby displaying the loaded messages withthe message to be currently transmitted within one conversational view.When the message to be currently transmitted corresponds to a start of anew message thread, a conversational view including only the message tobe currently transmitted will be displayed.

When the recipient included in the SIP message transmitted in step 411is the CPM client, the CPM server 20 transmits the message to acorresponding CPM client according to the same process as theconventional process.

FIG. 5 illustrates an operation process of the CPM client 10 accordingto an embodiment of the present invention, when the CPM client 10receives a CPM message including a thread ID.

Referring to FIG. 5, the CPM client 10 receives and analyzes a new SIPmessage in step 501, and then proceeds to step 503. In step 503, the CPMclient 10 checks if the SIP message includes a thread ID. When the SIPmessage does not include any thread ID, the CPM client 10 proceeds tostep 505, in which the CPM client simply displays the message in a newconversational view, and ends the procedure. When the SIP messageincludes a thread ID, the CPM client 10 proceeds to step 507, in whichthe CPM client 10 determines if the thread ID and a transmitter address(i.e. the associated originator user's address) included in the SIPmessage are stored in the thread database. The CPM client 10 proceeds tostep 509 when they are stored in the thread database, and proceeds tostep 511 when they are not stored in the thread database.

The fact that the received thread ID and the originator address arestored in the thread database implies that the message belongs to anexisting message thread. Therefore, the CPM client 10 loads theconversational view associated with the thread ID and the originatoruser in step 509, and then proceeds to step 513.

However, when the received thread ID and the originator address are notstored in the thread database, the message starts a new message thread.Then, the CPM client 10 stores the thread ID and originator's addressreceived in the thread database, and creates a new conversational viewassociated to them. Then, the CPM client 10 proceeds to step 513. Instep 513, the CPM client 10 adds the new message to the conversationalview and displays it to the recipient user. This ends the procedure ofthe CPM client 10.

As described above, each message transmitted/received for conversationalmessage communication between two CPM clients may include an identifierfor discriminating the message from another message transmitted to orreceived from another CPM client other than the two CPM clients.Therefore, the two CPM clients can group the messages exchanged betweenthem, so that the grouped messages can be provided to each user in aform of a conversational view.

Management and provision of such a message thread can be applied totransmission/reception of messages for conversational communicationbetween a CPM client and an MS for which SMS is supported. Therefore, itis possible to make this inter-working as seamless as possible, and theCPM user does not need to be aware of what messaging service therecipient supports.

In the case of message transmission/reception for conversationalcommunication between a CPM client and an MS to which SMS is supported,there are, in general, two methods for providing a message thread to aCPM client. According to the first method, a thread ID is included in anSIP message transmitted by a sender CPM client and a short messagetransmitted to a recipient in response to the SIP message. According tothe second method, an IWF for inter-working a CPM system and an SMSsystem stores and manages a thread ID allocated to a CPM client of atransmitter side and an MS of a receiver side, and the IWF provides aservice related to the thread ID only to the CPM client withoutproviding the thread ID to the MS.

An embodiment according to the first method may extend the thread IDinformation to the SMS domain. This involves additional informationelements in the SM sent to the SMS user, as well as adapted behaviorfrom the MS that receives the SM and sends a reply to it.

Hereinafter, the first method will be described with reference to FIGS.6 to 8.

FIG. 6 illustrates a message processing procedure of a short messagesystem and a CPM system inter-working with each other according to anembodiment of the present invention. Referring to FIG. 6, the CPM client10 transmits an SIP message including a message to be transmitted and athread ID through the CPM server 20 to the IWF 30 in steps 601 and 603.At this time, the process of configuring the SIP message by the CPMclient 10 is similar to the process shown in FIG. 4. When the IWF 30receives the SIP message in step 605, it proceeds to step 607. In step607, the IWF 30 converts the SIP message to an appropriate Short Message(SM). Then it proceeds to Step 609. The SM may be, for example, anSMS_SUBMIT PDU.

In step 609, the IWF 30 checks if the SIP message contains a thread ID.When a thread ID is present, the IWF 30 proceeds to step 611, and when athread ID is not present, the IWF 30 proceeds to step 619.

In step 611, the IWF 30 extracts the thread ID and incorporates theextracted thread ID in the SM. Then, the IWF 30 proceeds to step 613.

In step 613, the IWF 30 sends the converted SM to the SMSC 50. Then, instep 615, the IWF 30 transmits the SMS_SUBMIT PDU to the SMSC 50. Instep 617, the SMSC 50 transmits the message to the MS 60 through theSMS_SUBMIT PDU. In step 619, the MS 60 transmits SMS_DELIVER_REPORT PDUto the SMSC 50 and provides the message included in theSMS_DELIVER_REPORT PDU. In step 621, the SMSC 50 transmits theSMS_DELIVER_REPORT PDU to the IWF 30. Upon receiving theSMS_DELIVER_REPORT PDU in step 621, the IWF 30 transmits “200 OK”through the CPM server 20 to the CPM client 10 in steps 623 and 625.

Steps 609 and 611 can also occur at any time during the conversion instep 607.

In step 611, the IWF 30 includes the thread ID in the SM to be sent.According to an embodiment of the present invention, the thread ID maybe either included in a header of the TP-UD (User Data) of the SM, orincluded in a body part of the TP-UD, or included in a TP-DA(Destination-Address). When the thread ID is included in a header of theTP-UD of the SM, a new SMS information element is added. However, whenthe thread ID is included in a body part of the TP-UD or in a TP-DA, itis possible to construct a system without addition of a new informationelement.

When the thread ID is included in a header of the TP-UD of the SM, therecan be many ways for how exactly the thread ID is included in theheader. The present invention provides two embodiments, one of which isto include the thread ID in the SMSC control parameter included in theTP-UD, by referring to Table 8. The SMSC control parameter containsinformation that can be used to control the SMSC, but can also be passedtransparently to the recipient MS. The SMSC control parameter contains“Selective Status Report” as octet 1, which controls the creation ofstatus reports, depending on the error code of the particular message.The present invention adds a second octet as shown in Table 11.

TABLE 11 Reference Description octet 1 Selective This facility is usedto control the creation Status of Status Reports, depending on the errorcode Report of the particular message. It is also used by the sendingentity to request inclusion of the original UDH into the Status Report.In this case the original UDH must be separated from the rest of the UDHusing the Source Indicator. The TP-SRR must be set so that the SelectiveStatus Report to be enabled. octet 2 Message This facility is used toidentify the message thread ID thread this SM belongs to. The recipientMS must include this information in any reply to this message. The TP-RP(Reply Path) should be set when using this information.

The TP-RP (Reply Path) is included in both the SMS_SUBMIT andSMS_DELIVER PDUs to guarantee that the reply goes through the same SMSCthat delivered the original message, which guarantees that the SMSCknows the originator MS and is able to forward the reply to theoriginator.

According to another embodiment for including the thread ID in theheader of the TP-UD, a new information element identifier may be addedin the TP-UD header. That is, a new information element identifier named“Message Thread Information (MTI)” may be added in the TP-UD header.According to an embodiment of the present invention, the message threadinformation can be classified as SMS control and set to have norepeatability.

FIG. 7 illustrates a process of transmitting a short message by an MS 60in a case where a header of a TP-UD of a transmitted SM includes athread ID according to an embodiment of the present invention. Referringto FIG. 7, when an MS 60 receives a request for transmission of an SM instep 701, the MS 60 proceeds to step 703. In step 703, the MS 60 checksif the SM is a new message or the reply to a previously receivedmessage. When the SM is a reply, the MS 60 proceeds to step 705; whenthe SM is a new message, the message can be sent right away, so the MS60 proceeds to step 709.

In step 705, the MS 60 checks if the original message this SM isreplying to contains a thread ID in the header of the TP-UD informationelement. When the original message this SM is replying to contains athread ID in the header of the TP-UD information element, it proceeds tostep 707. When the original message this SM is replying to does notcontain a thread ID in the header of the TP-UD information element, itproceeds to step 709.

In step 707, the MS 60 extracts the thread ID and includes the extractedthread ID in the header of the TP-UD of the SM to be sent. Then, in step709, the MS 60 sends the SM to the SMSC 50.

The SMSC 50 transmits the received SM to the IWF 30, and the IWF 30having received the SM operates according to the process as shown inFIG. 8.

Referring to FIG. 8, when the IWF 30 receives an SM to be sent to theCPM client 10 in step 801, the IWF 30 converts the SM to an appropriateSIP message in step 803, and then proceeds to step 805.

In step 805, the IWF 30 checks if the SM contains a thread IDinformation in the header of the TP-UD information element. When athread ID is present, the IWF 30 proceeds to step 807, and when it isnot, the IWF 30 proceeds to step 809, in which the IWF 30 transmits theSIP message converted in step 803.

In step 807, the IWF 30 extracts the thread ID from the TP-UD of the SMand incorporates the extracted thread ID in the SIP message as an XMLdocument format, as shown in Table 9, and then proceeds to step 809, inwhich the IWF 30 transmits the SIP message to the CPM server 20. Steps805 and 807 may be performed while the SM is converted to the SIPmessage in step 803.

According to another embodiment of the present invention, the thread IDinformation may be appended in the existing SMS TP-DA (DestinationAddress) information element, using the existing sub-addressing andreply-path mechanisms.

Rules for sub-addressing in the existing SMS are as follows:

An originating MS may send an SM with ‘*’s or ‘#’s included in the TP-DAfield. The first ‘#’ encountered in the TP-DA indicates where theaddress for SMSC routing purposes is terminated. Additional ‘*’s or ‘#’scan be present in the following digits, and all these digits includingthe first ‘#’ are subaddress digits.

When the SMSC receives an SM to convey with such a subaddressinformation, the SMSC should deliver the SM to the destination MS withthe same subaddress digits copied in the TP-OA field.

For example, when MS A having an address of 987654321 sends an SM withTP-DA of 1234#56#789* to MS B, MS B having an address of 1234 willreceive the SM with TP-OA of 987654321#56#789*.

Further, a common procedure for the reply-path mechanism is as follows.

The reply path is requested by the originating MS by setting theTP-Reply-Path parameter in the SMS SUBMIT PDU of the original SM. Whenthe original SMSC supports reply path requesting for the originating MS,it shall take notice of the TP-Reply-Path (TP-RP) parameter in theSMS-SUBMIT PDU and set the TP-RP parameter in the SMS-DELIVER PDU of theoriginal MT SM towards the replying MS. Hence, a reply path exists forthe replying MS towards the originating MS.

When a replying MS receives an original SM, it then has an originatingMS address and a reply path mechanism.

The originating MS address is found in the TP-Originating-Address in theSMS-DELIVER PDU, and existence of the reply path is determined based onif the TP-RP has been set in SMS-DELIVER PDU.

When submitting the reply SM and when the reply-path is set, thereplying MS should use the Originating MS address (content ofTP-Originating-Address) as the TP-Destination-Address in SMS-SUBMIT PDUand submits it to the SMSC that delivered the original SM.

The original SM and the reply SM are delivered by the same SMSC. Thisprinciple maximizes the probability that the SC can e.g. route the replySM to the proper data network for reaching the originating MS.

Hereinafter, a method for conveying the thread ID information withoutimpacting the existing SMS system, by using the sub-addressing andreply-path mechanisms and the TP-DA, will be described.

When the IWF 30 receives a SIP message that includes a thread ID and istargeting the MS 60, the IWF 30 converts the received SIP message to anSM and appends the thread ID in the TP-DA information element of theSMS_SUBMIT PDU that contains the SM, as if the thread ID were asub-address, i.e. <dest_address>#<thread_id>. When the original threadID is not formed of digits, the IWF 30 needs to convert the thread ID toa unique digit sequence and keeps a mapping table between the originalthread ID and the corresponding sequence in the TP-DA. The IWF 30 alsosets the TP-RP (Reply Path) bit to “1”, requesting therefore that thereplying MS submits any reply SM to the same SMSC from which it receivedthe original SM.

Thereafter, the IWF 30 sends an SMS_SUBMIT PDU to the SMSC 50. The SMSC50 converts the SMS_SUBMIT PDU to SMS_DELIVER PDU and transmits theconverted PDU to the MS 60. The MS 60 receives the SM from the SMSC 50in an SMS_DELIVER PDU, that contains a TP-OA information element withthe thread ID information as sub-address.

When the MS 60 sends a reply SM for the received SM, the MS 60 includesthe entire content of the TP-OA of the SMS_DELIVER PDU of the receivedoriginal SM, i.e. including the thread ID, in the TP-DA of theSMS_SUBMIT PDU of the reply SM, as per the reply path procedure.

Further, the MS 60 sends the reply SM to the IWF 30 via the SMSC 50,which copies the thread ID in the TP-OA of the SMS_DELIVER PDU deliveredto the IWF 30.

When the IWF 30 receives the SMS_DELIVER PDU, the IWF 30 extracts thethread ID from the TP-OA information element and converts the SM to anappropriate SIP MESSAGE. The thread ID is also included in the SIPMESSAGE using the XML format described above. At this time, the threadID may need to be converted back to the original alphanumeric thread IDsequence using the mapping table described above.

Thereafter, the IWF 30 sends the SIP message to the CPM Server 20.

Another embodiment for inserting the thread ID in the SM includes amethod of inserting the thread ID in the body part of the SM, whichcorresponds to usage SMS-Email inter-working functionality.

In SMS-Email inter-working, the basic syntax is as follows:

- When receiving an SM: [<from-address><space>]<message> - When sendingan SM: [<to-address><space>]<message> where [ ] are optional fields. The“from-address” and “to-address” can be either “user@domain1.domain2” or“User Name <user@domain1.domain2>” (in this case, the <> can also betransmitted).

It is also possible to include an optional subject for the message asfollows:

[<to-address>](<subject>)<message>; or[<to-address>]##<subject>#<message>.

Based on the above, a possible solution is to insert the thread IDinstead as the “subject” of the message.

That is, when the IWF 30 receives a SIP message including a thread ID,the IWF 30 converts the SIP message to an SM and includes the thread IDas a subject in the body part of the TP-UD of the SMS_SUBMIT PDU:“##<thread ID>#<message>”. The <to-address> could also be added byextracting the address (user@domain1.domain2) from the “To:” field ofthe SIP message.

The IWF 30 sends the SMS_SUBMIT PDU that contains the SM to the SMSC 50.Then, the MS 60 receives the SM from the SMSC 50 in an SMS_DELIVER PDU,that contains the thread ID information in the body part of the TP-UD.When the MS 60 sends a reply, it follows the same syntax, so includesthe same subject (i.e. the thread ID) of the original message in theTP-UD. The MS 60 sends an SMS_SUBMIT PDU including the reply SM to theSMSC 50, and the SMSC 50 transmits the SMS_DELIVER PDU corresponding tothe SMS_SUBMIT PDU to the IWF 30.

When the IWF 30 receives the SMS_DELIVER PDU, the IWF 30 extracts thethread ID from the subject of the received SM, that is, the SMS_DELIVERPDU. Further, the IWF 30 converts the SM to an appropriate SIP message,includes the thread ID in the SIP message using the XML format describedabove, and then sends the SIP message to the CPM Server 20.

All of the embodiments described above correspond to cases where both anSIP message transmitted by an originator CPM client and an SMtransmitted to a recipient in response to the SIP message include athread ID. According to the following embodiment described below, an IWFinter-working a CPM system and an SMS system stores and manages a threadID allocated in accordance with an originator CPM client and a recipientMS, and does not provide the thread ID to the MS. This embodiment can beimplemented without changing the conventional SMS system.

According to the present embodiment, the IWF simulates the existence ofa thread in the SMS domain by storing the “thread ID, originator'saddress, recipient's address” in the IWF during a certain amount oftime. FIG. 9 illustrates a message processing procedure by a CPM systemand an SM system inter-working with each other.

In steps 901 and 903, the CPM client 10 sends an SIP message including athread ID and a message to be transmitted via the CPM server 20 to theIWF 30. Here, the process of configuring the SIP message by the CPMclient 10 is similar to the process shown in FIG. 4. The IWF 30 detectsthe thread ID, originator address, and recipient address, stores thedetected information in the database, and then converts the SIP messageto an appropriate SM. Thereafter, in step 907, the IWF 30 transmits anSMS_SUBMIT PDU including the converted SM to the SMSC 50. In step 909,the SMSC 50 transmits the message through the SMS_DELIVER PDU to the MS60. Upon receiving the SMS_DELIVER PDU, the MS 60 sends anSMS_DELIVER_REPORT PDU to the SMSC 50 and provides the message includedin the SMS_DELIVER PDU to the user, although not shown in the drawings.Further, the SMSC 50 transmits the SMS_STATUS_REPORT PDU to the IWF 30.Upon receiving the SMS_STATUS_REPORT PDU, the IWF 30 transmits “200 OK”to the CPM client 10 via the CPM server 20.

The MS 60 sends an SMS_SUBMIT PDU, which includes a reply message to themessage received by the MS 60 in step 909, to the SMSC 50 in step 911.In step 913, the SMSC 50 sends a reply message through an SMS_DELIVERPDU to the IWF 30. In step 915, the IWF 30 detects the originatoraddress and the recipient address included in the SMS_DELIVER PDU, andthen obtains a thread ID corresponding to the originator address and therecipient address from the database. Then, in step 917, the IWF 30converts the reply message to an SIP message, inserts the obtainedthread ID in the SIP message, and then transmits the SIP message to theCPM server 20. In step 919, the CPM server 20 sends the SIP message tothe CPM client 10.

The detailed procedure at the IWF 30 is illustrated in FIG. 10.Referring to FIG. 10, in step 1000, the IWF 30 waits an event to occur.Here, the event implies either reception of an SIP message or an SM orexpiration of a valid reply period.

When a SIP message is received from the CPM server 20, the IWF 30proceeds to step 1001. When an SM is received from the CPM server 20,the IWF 30 proceeds to step 1101. Further, when a valid reply periodassociated to a thread ID expires, the IWF 30 proceeds to step 1201.

First, a case where the IWF 30 receives an SIP message is described.Upon receiving the SIP message, the IWF 30 checks if the SIP messagecontains a thread ID in step 1001. When the SIP message contains athread ID in step 1001, the IWF 30 proceeds to step 1003, otherwise theIWF 30 proceeds to step 1011. In step 1003, the IWF 30 extracts thethread ID, originator's address, and recipient's address from the SIPmessage, and then proceeds to step 1005. In step 1005, the IWF 30 checksif the extracted three pieces of information is in its database. Whenthere is no such information, the IWF 30 proceeds to step 1007. Whenthere is the extracted three pieces of information, the IWF 30 proceedsto step 1009. In step 1007, the fact that there is no such informationimplies that the SIP message is the first message of a new messagethread (or the thread existed, but expired). The IWF 30 stores thethread ID, originator's address, and recipient's address in its databaseand starts a timer with a predefined valid reply period for this thread,and then proceeds to step 1011. The timer and valid reply period givethe lifetime of the thread management by the IWF 30. That is, when amessage associated with a corresponding thread ID is not received withinthe valid reply period, the corresponding thread ID and associatedaddress information are deleted. Further, when the thread ID,originator's address, and recipient's address are found, it implies thatthe SIP message is a follow-up message of an existing message thread.Therefore, in step 1009, when the thread ID, originator's address, andrecipient's address are found in the database, the IWF 30 recognizesthat the thread is still active, and resets the timer associated withthe thread to zero, to extend the lifetime management of the thread.Then, the IWF 30 proceeds to step 1011. In step 1011, the IWF 30converts the SIP message to an appropriate SM and sends the SM to theSMSC 50 (note that no thread ID is included in the SM). Then, the IWF 30returns back to step 1000 to wait for any new event.

When the IWF 30 receives an SM while it waits for occurrence of anevent, the IWF 30 proceeds to step 1101, in which the IWF 30 convertsthe SM to an SIP message. Then, in step 1103, the IWF 30 checks if thepair “originator's address-recipient's address” of the SIP message is inits database. When the pair “originator's address-recipient's address”of the SIP message is in its database, the IWF 30 proceeds to step 1105.When the pair “originator's address-recipient's address” of the SIPmessage is not in its database, the IWF 30 considers the SIP message isthe first message of a new thread or is not associated with the thread,and then proceeds to step 1111. In step 1105, the IWF 30 extracts thethread ID corresponding to the pair of addresses, and then proceeds tostep 1107. In step 1107, the IWF 30 includes the extracted thread ID inthe SIP message, and then proceeds to step 1109. In step 1109, the IWF30 resets the timer associated with this thread ID to zero: since amessage belonging to an existing thread has arrived, the lifetime of thethread ID is extended in the database so that it can continue to bemanaged. Then, the IWF 30 proceeds to step 1111, in which the IWF 30sends the resulting SIP message to the CPM server 20. Then, the IWF 30returns to step 1000 to wait for a new event.

When an event of expiration of a valid reply period corresponding to athread ID occurs, the IWF 30 removes the corresponding thread ID,originator's address and recipient's address from the database in step1201. Then, the IWF 30 returns to Step 1000 to wait for a new event.

As described above, the present invention provides methods for managingmultiple message threads for the CPM service and for the CPM-SMSinter-working. The benefits of the present invention are:

The ability for a CPM user to handle a message-based conversation withanother CPM user, without the need to explicitly initiate a sessionbeforehand.

The ability for a CPM user to view all messages related to the samethread in a same conversational view.

The ability for a CPM user to have a message-based conversation with anSMS user and to benefit of the same message thread and conversationalview features. The CPM user does not need to be aware that the otherparty does not support CPM but only SMS.

While the invention has been shown and described with reference tocertain exemplary embodiments thereof, it will be understood by thoseskilled in the art that various changes in form and details may be madetherein without departing from the spirit and scope of the invention asdefined by the appended claims.

1 A Converged Internet Protocol Message (CPM) system for managingmultiple message threads and supporting a Session Initiation Protocol(SIP) based Converged Internet Protocol Messaging Service (CPMS), theCPM system comprising: a CPM client for which the CPMS is supported; anon-IP Multimedia Subsystem (IMS) client that has not joined an IMSservice; and an Inter-Working Function (IWF) for, when a recipientclient of the CPM client is appointed as the non-IMS client by a CPMserver and the IWF receives an SIP message for conversational messagecommunication, converting a message format of the SIP message into amessage format that can be received by the recipient client, inserting athread identifier (ID) included in the SIP message into the convertedmessage, and transmitting the converted message to the recipient clientvia a server supporting the recipient client.
 2. The CPM system of claim1, wherein: the non-IMS client that has not joined the IMS service is aMobile Station (MS) for which a Short Message Service (SMS) issupported; the IWF converts the SIP message to an SMS SUBMIT ProtocolData Unit (SMS_SUBMIT PDU), inserts the thread ID into a controlparameter of a TP user data header of the SMS_SUBMIT PDU, and transmitsthe control parameter to a Short Message Service Center (SMSC); and theSMSC receives the SMS_SUBMIT PDU, converts the SMS_SUBMIT PDU to an SMSDELIVERY Protocol Data Unit (SMS_DELIVER PDU), inserts the thread IDinto a control parameter of a TP user data header of the SMS_DELIVERPDU, and transmits the control parameter to the MS.
 3. The CPM system ofclaim 1, wherein: the non-IMS client that has not joined the IMS serviceis an MS for which an SMS is supported; the IWF converts the SIP messageto an SMS_SUBMIT PDU, inserts the thread ID into a message threadinformation field of a TP user data header of the SMS_SUBMIT PDU, andtransmits the control parameter to an SMSC; and the SMSC receives theSMS_SUBMIT PDU, converts the SMS_SUBMIT PDU to an SMS_DELIVER PDU,inserts the thread ID into a message thread information field of a TPuser data header of the SMS_DELIVER PDU, and transmits the controlparameter to the MS.
 4. A Converged Internet Protocol Message (CPM)system for managing multiple message threads and supporting a SessionInitiation Protocol (SIP) based Converged Internet Protocol MessagingService (CPMS), the CPM system comprising: a CPM client for which theCPMS is supported; a non-IP Multimedia Subsystem (IMS) client that hasnot joined an IMS service; and an Inter-Working Function (IWF) for, whena recipient client of the CPM client is appointed as the non-IMS clientby a CPM server and the IWF receives an SIP message for conversationalmessage communication, detecting and storing a thread identifier (ID)from the SIP message, converting a message format of the SIP messageinto a message format that can be received by the recipient client,transmitting the converted message to the recipient client via a serversupporting the recipient client, converting a message received from therecipient client within a predetermined valid reply period to an SIPmessage, inserting the stored thread ID into the converted SIP message,and transmitting the SIP message to the CPM client via the CPM server.5. The CPM system of claim 4, wherein the IWF deletes the stored threadID when there is no message received from the recipient client withinthe valid reply period.
 6. The CPM system of claim 5, wherein, when therecipient client of the CPM client is appointed as the non-IMS client bythe CPM server and the IWF receives an SIP message for conversationalmessage communication, the IWF detects the thread ID, a recipientaddress, and an originator address from the SIP message, checks if athread ID, a recipient address, and an originator address correspondingto the detected thread ID, the recipient address, and the originatoraddress are stored in a database, stores the detected thread ID, therecipient address, and the originator address and sets the valid replyperiod when the corresponding thread ID, the recipient address, and theoriginator address are stored in the database, resets the valid replyperiod previously set in accordance with the detected thread ID when thecorresponding thread ID, the recipient address, and the originatoraddress are not stored in the database, converts the message format ofthe SIP message into the message format that can be received by therecipient client, and transmits the converted message to the recipientclient via the server supporting the recipient client.
 7. The CPM systemof claim 5, wherein, when the IWF receives a message from the serversupporting the recipient client, the IWF detects a recipient address andan originator address from the received message, checks if a recipientaddress and an originator address corresponding to the detectedrecipient address and the originator address are stored in a database,extracts a thread ID corresponding to the addresses, converts a messageformat of the received message into the message format of the SIPmessage, resets a valid reply period corresponding to the thread ID,inserts the thread ID into the message, and transmits the convertedmessage to the CPM client.
 8. A Converged Internet Protocol Message(CPM) system for managing multiple message threads and supporting aSession Initiation Protocol (SIP) based Converged Internet ProtocolMessaging Service (CPMS), the CPM system comprising: a CPM client forwhich the CPMS is supported; a Mobile Station (MS) for which a ShortMessage Service (SMS) is supported; an Inter-Working Function (IWF) for,when a recipient client of the CPM client is appointed as the MS by aCPM server and the IWF receives an SIP message for conversationalmessage communication, converting a message format of the SIP messageinto a message format of an SMS SUBMIT Protocol Data Unit (SMS_SUBMITPDU), setting sub-address digits of a TP destination address of theSMS_SUBMIT PDU to a thread identifier (ID) detected from the SIPmessage, and transmitting the SMS_SUBMIT PDU to a Short Message ServiceCenter (SMSC); and the SMSC for receiving the SMS_SUBMIT PDU, convertingthe SMS_SUBMIT PDU to an SMS DELIVERY Protocol Data Unit (SMS_DELIVERPDU), setting sub-address digits of a TP originator address of theSMS_DELIVERY PDU to the thread ID, and transmitting the SMS_DELIVERY PDUto the MS.
 9. A method for managing a message thread including a seriesof messages transmitted to and received from a same counterpart by aConverged Internet Protocol Message (CPM) client supporting a SessionInitiation Protocol (SIP) based Converged Internet Protocol MessagingService (CPMS), the method comprising the steps of: receiving a requestfor transmission of a message for conversational message communicationfrom a recipient; when the message is a first message of a new messagethread associated with the recipient, allocating a new thread ID to thenew message thread, storing the new thread identifier (ID) in relationto the recipient, inserting the new thread ID into the message, andtransmitting the message; when the message is a subsequent message in anexisting message thread associated with the recipient, detecting athread ID allocated in accordance with the existing message thread,inserting the allocated thread ID in the message, and transmitting themessage; receiving the message for conversational message communication;and when the received message includes a thread ID, providing a userwith the received message with messages included in a message threadcorresponding to the thread ID included in the received message.
 10. Amethod for managing a message thread including a series of messagestransmitted to and received from a same counterpart by a ConvergedInternet Protocol Message (CPM) client supporting a Session InitiationProtocol (SIP) based Converged Internet Protocol Messaging Service(CPMS), the method comprising the steps of: transmitting, by a CPMclient for conversational message communication, an SIP message thatincludes a thread identifier (ID) allocated to a message threadassociated with a recipient appointed as a non-IP Multimedia Subsystem(IMS) client that has not joined an IMS service; and when anInter-Working Function (IWF) receives the SIP message through a CPMserver, converting a message format of the SIP message into a messageformat that can be received by the recipient, inserting the thread ID inthe converted message, and transmitting the converted message to therecipient, by the IWF.
 11. The method of claim 10, further comprising:when the recipient is a Mobile Station (MS) for which a Short MessageService (SMS) is supported, converting the SIP message into an SMSSUBMIT Protocol Data Unit (SMS_SUBMIT PDU), inserting the thread ID intoa control parameter of a TP user data header of the SMS_SUBMIT PDU, andtransmitting the SMS_SUBMIT PDU to a Short Message Service Center(SMSC), by the IWF; and when the SMSC receives the SMS_SUBMIT PDU,converting the SMS_SUBMIT PDU into an SMS DELIVERY Protocol Data Unit(SMS_DELIVER PDU), inserting the thread ID into a control parameter of aTP user data header of the SMS_DELIVER PDU, and transmitting theSMS_DELIVER PDU to the MS, by the SMSC.
 12. The method of claim 10,further comprising: when the recipient is an MS for which an SMS issupported, converting the SIP message into an SMS_SUBMIT PDU, insertingthe thread ID into a message thread information field of a TP user dataheader of the SMS_SUBMIT PDU, and transmitting the SMS_SUBMIT PDU to anSMSC, by the IWF; and when the SMSC receives the SMS_SUBMIT PDU,converting the SMS_SUBMIT PDU into an SMS_DELIVER PDU, inserting thethread ID into a message thread information field of a TP user dataheader of the SMS_DELIVER PDU, and transmitting the SMS_DELIVER PDU tothe MS, by the SMSC.
 13. The method of claim 10, further comprising:when the recipient is an MS for which an SMS is supported, convertingthe SIP message into an SMS_SUBMIT PDU, inserting the thread ID into abody of a TP user data header of the SMS_SUBMIT PDU, and transmittingthe SMS_SUBMIT PDU to an SMSC, by the IWF; and when the SMSC receivesthe SMS_SUBMIT PDU, converting the SMS_SUBMIT PDU into an SMS_DELIVERPDU, inserting the thread ID into a body of a TP user data header of theSMS_DELIVER PDU, and transmitting the SMS_DELIVER PDU to the MS, by theSMSC.
 14. The method of claim 10, further comprising: when the recipientis an MS for which an SMS is supported, converting the SIP message intoan SMS_SUBMIT PDU, setting sub-address digits of a TP destinationaddress of the SMS_SUBMIT PDU to the thread ID, and transmitting theSMS_SUBMIT PDU to an SMSC, by the IWF; and receiving the SMS_SUBMIT PDU,converting the SMS_SUBMIT PDU into an SMS_DELIVER PDU, settingsub-address digits of a TP originator address of the SMS_DELIVER PDU tothe thread ID, and transmitting the SMS_DELIVER PDU to the MS, by theSMSC.
 15. A method for managing a message thread including a series ofmessages transmitted to and received from a same counterpart in aConverged Internet Protocol Message (CPM) system supporting a SessionInitiation Protocol (SIP) based Converged Internet Protocol MessagingService (CPMS), the method comprising the steps of: transmitting, by aCPM client for conversational message communication, an SIP message thatincludes a thread identifier (ID) allocated to a message threadassociated with a recipient appointed as a non-IP Multimedia Subsystem(IMS) client that has not joined an IMS service; and when anInter-Working Function (IWF) receives the SIP message through a CPMserver, storing the thread ID, an address of the CPM client, and arecipient address, setting a predetermined valid reply periodcorresponding to the thread ID, converting a message format of the SIPmessage into a message format that can be received by the recipient, andtransmitting the converted SIP message to the recipient through a serversupporting the recipient, by the IWF; and when the IWF receives amessage from the recipient within the predetermined valid reply period,converting the message received from the recipient into the SIP message,inserting the stored thread ID into the SIP message, and transmittingthe SIP message to the CPM client via the CPM server, by the IWF. 16.The method of claim 15, further comprising deleting the stored thread IDby the IWF when there is no message received from the recipient clientwithin the valid reply period.
 17. The method of claim 15, whereinconverting a message format of the SIP message into a message formatthat can be received by the recipient and transmitting the converted SIPmessage to the recipient through a server supporting the recipient bythe IWF comprises: searching a database for the thread ID, the addressof the CPM client, and the recipient address; when the thread ID, therecipient address, and an originator address are not included in thedatabase, storing the thread ID, the recipient address, and theoriginator address in the database and setting the valid reply period;when the thread ID, the recipient address, and the originator addressare included in the database, resetting the valid reply periodpreviously set in accordance with the thread ID; and converting amessage format of the SIP message into a message format that can bereceived by the recipient client, and transmitting the converted messageto the recipient via the server supporting the recipient client.
 18. Themethod of claim 17, wherein converting the message received from therecipient into the SIP message, inserting the stored thread ID into theSIP message, and transmitting the SIP message to the CPM client via theCPM server by the IWF comprises: when the IWF receives a message withinthe valid reply period from the recipient, detecting a recipient addressand an originator address included in the received message; when thedatabase includes a recipient address and an originator addresscorresponding to the detected addresses, extracting a thread IDcorresponding to the addresses; and resetting the valid reply periodcorresponding to the thread ID, converting a message format of themessage into a message format of the SIP message, inserting theconverted message format into the thread ID, and transmitting theconverted message to the CPM client.